itlawwikiaorg-20200214-history
Cloud computing terms of service
Overview '''Cloud computing terms of service''' are determined by a legally binding [[agreement]] between the [[subscriber]] and the [[cloud provider]] often contained in two parts: (1) a service agreement, and (2) a [[Service Level Agreement]] ([[SLA]]). Generally, the service agreement is a legal document specifying the rules of the legal [[contract]] between a [[subscriber]] and [[cloud provider|provider]], and the [[SLA]] is a shorter document stating the technical performance promises made by a provider including [[remedies]] for performance failures. For simplicity, the following discussion refers to the combination of these two documents as an SLA.Some [[cloud provider]]s historically have not provided [[SLA]]s, or have provided them only to large or persistent users. An [[SLA]] is extremely important to understand a [[cloud provider]]’s promises. Although the self-service aspect of a [[cloud]] implies that a [[subscriber]] either (1) [[accept]]s a [[cloud provider|provider]]’s pricing and [[SLA]], or (2) finds a [[cloud provider|provider]] with more acceptable terms, potential [[subscriber]]s anticipating heavy use of [[cloud]] resources may be able to [[negotiate]] more favorable terms. For the typical [[subscriber]], however, a [[cloud]]’s pricing policy and [[SLA]] are nonnegotiable. Published [[SLA]]s between [[subscriber]]s and [[cloud provider|providers]] can typically be [[terminated]] at any time by either party, either “[[for cause]]” such as a [[subscriber]]’s violation of a [[cloud]]’s [[acceptable use policies]], or for failure of a [[subscriber]] to pay in a timely manner. Further, an [[agreement]] can be [[terminated]] for no reason at all. [[Subscriber]]s should analyze [[cloud provider|provider]] [[termination]] and [[data retention]] policies. [[cloud provider|Provider]] promises, including explicit statements regarding limitations, are codified in their [[SLA]]s. A [[cloud provider|provider]]’s [[SLA]] has three basic parts: (1) a collection of promises made to [[subscriber]]s, (2) a collection of promises explicitly not made to [[subscriber]]s, i.e., limitations, and (3) a set of obligations that [[subscriber]]s must [[accept]]. Promises Generally, [[cloud provider]]s make four key promises to [[subscriber]]s: * '''Availability.''' [[cloud provider|Providers]] typically advertise [[availability]] promises as [[uptime]] percentages ranging from 99.5%-100%. These are strong claims, and care is needed to understand how these percentages are calculated. Often, the percentage applies to the number of time intervals within a billing cycle (or longer periods such as a year) in which services are not “up” for the entire interval. Examples of time intervals used by prominent providers are 5 minutes, 15 minutes, and 1 hour. For example, if a provider specifies an [[availability]] interval of 15 minutes, and the service is not functional for 14 minutes, 100% [[availability]] is preserved using this [[metric]]. Generally, the definition of “up” is intuitively defined as service [[responsiveness]], but in some cases, multiple [[cloud]] subsystems must fail before the service is judged as unavailable. Providers may also limit [[availability]] promises if failures are specific to particular functions or [[Virtual Machine]]s ([[VM]]s). * '''Remedies for Failure to Perform.''' If a [[cloud provider|provider]] fails to give the promised [[availability]], a provider should compensate [[subscriber]]s in [[good faith]] with a service credit for future use of [[cloud service]]s. Service credits can be computed in different ways, but are usually determined by how long the service was unavailable within a specific billing period. Service credits are generally capped not to exceed a percentage of a [[subscriber]]’s costs in the billing period in which [[downtime]] occurred. Typical caps range from 10% to 100% of a [[subscriber]]’s current costs, depending on the [[cloud provider|provider]]. Responsibility for obtaining a service credit is generally placed on the [[subscriber]], who must provide timely information about the nature of the [[outage]] and the time length of the [[outage]]. It is unclear whether a [[cloud provider|provider]] will voluntarily inform a [[subscriber]] of a service [[disruption]]. * '''Data Preservation.''' If a [[subscriber]]’s [[access]] to [[cloud service]]s is [[terminated]] “[[for cause]],” i.e., because the [[subscriber]] has violated the [[cloud]]s' [[acceptable use policy]] or for nonpayment, most [[cloud provider|providers]] state that they have no obligation to [[preservation|preserve]] any [[subscriber]] [[data]] remaining in [[cloud storage]]. Further, after a [[subscriber]] voluntarily stops using a [[cloud]], [[cloud provider|providers]] generally state that they will not [[intentional]]ly erase the [[subscriber]]’s [[data]] for a period of 30 days. Some [[cloud provider|providers]] preserve only a snapshot of [[subscriber]] [[data]], or recommend that [[subscriber]]s: (1) [[backup]] their [[data]] outside that [[cloud provider|provider]]’s [[cloud]] inside another [[cloud provider|provider]]’s [[cloud]], or (2) [[backup|back it up]] locally. * '''Legal Care of Subscriber Information.''' Generally, [[cloud provider|providers]] promise not to [[sell]], [[license]], or [[disclose]] [[subscriber]] [[data]] except in response to legal requests. [[cloud provider|Providers]], however, usually reserve the right to [[monitor]] [[subscriber]] actions in a [[cloud]], and they may even demand a [[copy]] of [[subscriber]] [[software]] to assist in that [[monitor]]ing. Limitations Generally, [[cloud provider|provider]] policies include five key limitations: * '''Scheduled Outages.''' If a [[cloud provider|provider]] announces a scheduled service [[outage]], the [[outage]] does not count as failure to perform. For some [[cloud provider|providers]], [[outage]]s must be announced in advance, or must be bounded in duration. * '''Force majeure events.''' Providers generally [[disclaim]] all responsibility for events outside their realistic control. Examples include power failures, natural disasters, and failures in [[network connectivity]] between [[subscriber]]s and [[cloud provider|providers]]. * '''SLA Changes.''' [[cloud provider|Providers]] generally reserve the right to change the terms of the [[SLA]] at any time, and to change pricing with limited advanced notice. For standard [[SLA]] changes, notice is generally given by a [[cloud provider|provider]] by [[post]]ing the change to a [[Web site]]. It is then the [[subscriber]]’s responsibility to periodically check the [[Web site]] for changes. Changes may take effect immediately or after a delay of several weeks. For changes that affect an individual [[subscriber]]’s account, notice may be delivered via [[email]] or a delivery service. * '''Security.''' [[cloud provider|Providers]] generally assert that they are not responsible for [[security]], i.e., [[unauthorized]] [[modification]] or [[disclosure]] of [[subscriber]] [[data]], or for service [[interruption]]s caused by [[malicious]] activity. Generally, [[SLA]]s are explicit about placing [[security]] [[risk]]s on [[subscriber]]s. In some cases, [[cloud provider|providers]] promise to use [[best efforts]] to protect [[subscriber]] [[data]], but [[disclaim]] [[security]] responsibility for [[data breach]], [[data loss]], or service [[interruption]]s by limiting [[remedies]] to service credits for failure to meet [[availability]] promises. Further, it is unclear how easy it would be for a [[subscriber]] to determine that a service [[disruption]] was [[malicious]]ly induced versus induction from another source. * '''Service API Changes.''' [[cloud provider|Providers]] generally reserve the right to change or delete service [[API]]s at any time. Obligations Generally, [[subscriber]]s must agree to three key obligations: * '''Acceptable Use Polices.''' [[Subscriber]]s generally must agree to refrain from [[storing]] illegal [[content]], such as [[child pornography]], and from conducting illegal activities such as: (1) [[gambling]], (2) sending [[spam]], (3) conducting [[security attack]]s (e.g., [[denial of service]] or [[hacking]]), (4) [[distributing]] [[spyware]], (5) [[intrusive]] [[monitor]]ing, and (6) attempting to [[subvert]] [[cloud system]] [[infrastructure]]s. [[Acceptable use policies]] vary among [[cloud provider|providers]]. * '''Licensed Software.''' All [[cloud provider|providers]] state that [[third-party]] [[software]] [[run]]ning in their [[cloud]]s must conform to the [[software]]’s [[license]] terms. In some cases, [[cloud provider|providers]] [[bundle]] such [[software]] and include [[monitor]]ing to ensure that [[license]] restrictions are enforced. * '''Timely Payments.''' [[Cloud service]] costs are generally incurred gradually over a billing period, with the fee due to the [[cloud provider|provider]] at the period’s end. Failure to pay, after a [[grace period]], usually subjects a [[subscriber]] to [[suspension]] or [[termination]] “[[for cause]]” which can result in loss of [[subscriber]] [[data]]. References Source * [[NIST Special Publication 800-145]], at 3-1 to 3-3. [[Category:Contract]] [[Category:Cloud computing]] Recommendations * Terminology. Subscribers should pay close attention to the terms that are used in SLAs. Common terms may be redefined by a cloud provider in ways that are specific to that provider's offerings. * Remedies. Unless a specific SLA has been negotiated with a provider, remedies for any failures are likely to be extremely limited; subscribers may wish to formulate remedies that are commensurate with damage that might be sustained. * Compliance. Subscribers should carefully assess whether the SLA specifies compliance with appropriate laws and regulations governing subscriber data. * Security, Criticality, and Backup. Subscribers should carefully examine the SLA for any disclaimers relating to security or critical processing, and should also search for any comment on whether the provider recommends independent backup of data stored in their cloud. * Negotiated SLA. If the terms of the default SLA do not address all subscriber needs, the subscriber should discuss modifications of the SLA with the provider prior to use. References